Link failure recovery method and apparatus

ABSTRACT

A method of routing packets across a packet switched network domain, comprising a multiplicity of nodes. Each node comprises an ingress interface and an egress interface. For each destination node a default and a detour branching are defined, each specifying a route to the destination node. For each two-edge connected node the default and detour branchings do not share a common ingress interface. Each node operates as an intermediate node receiving a packet at an ingress interface, identifying an egress interface based upon the ingress interface upon which the packet is received and the packet destination, forwarding the packet via that egress interface if the connected link is available and, if the connected link is not available, forwarding the packet via an alternative egress interface associated with said detour branching if the packet was received at an ingress interface associated with said default branching or dropping the packet if the packet was received at an ingress interface associated with said detour branching.

TECHNICAL FIELD

The present invention relates to an Link failure recovery method andapparatus and in particular to such a method and apparatus which avoidsrouting loops.

BACKGROUND

A typical Internet Protocol (IP) network comprises a set of IP routerseach having one or more ingress interface and one or more egressinterfaces (typically, for duplex links, a single interface will actboth as ingress and egress interface). Each interface is attached to alink which carries packets between routers. A link may be for example anEthernet link, optical link, etc. Within a router, each ingressinterface is part of a so-called line card. This line card connects theinterface to the internal backplane of the node. Each line card has amemory storing a routing table sometimes referred to as forwardingtable. A routing table stores for each destination IP address prefix anegress interface. When a packet is received at an ingress interface of arouter, the corresponding line card uses its routing table to determinefrom the IP Address prefix the egress interface over which the packetshould be sent. Conventionally, a routing table is computed by softwarerunning at an IP router, with the same table being provided to each linecard of that router.

Failures of IP links within an IP network can be fairly common. Afailure may result due to failure of a link itself, or due to failure ofa node at the other end of a link. Various fault recovery procedures arein use to mitigate the effects of link failures. Typically, these relyupon a router detecting a failure in respect of a link to which therouter is directly connected. The router then “floods” the change oflink state as a protocol message to all its neighbours, which in turnalso flood the link state update to all their neighbour until allnetwork routers learn about the topology change. After learning thechange of link state, either by direct detection or by being informedvia a signaling message, each router re-computes its routing table toprovide alternative routes (if available) which avoid the failed link.The re-computed table is passed to each line card at the router. Each IProuter of the network re-computes its own routing table. Examples ofsuch conventional protocols include Open Shortest Path First (OSPF) andIntermediate System-to-Intermediate System (IS-IS).

It takes a significant time for a fault detection at one IP router topropagate to other routers with a network and to effect the routingtables used by the line cards at those other routers due to linktransmission delays and to the time taken to recompute the routingtables and store these in the link cards. Even though an individualrouter (e.g. the one that detects the failure) might update its routingtable quickly, this will not be effective until other routers havesimilarly recomputed their routing tables. In the meantime, packets canbe dropped and service levels reduced.

In an attempt to mitigate these problems, a new IP Fast Reroute (IPFRR)framework (see references [1] to [5] below) has been proposed. Theobject of IPFRR framework is to allow individual routers to quicklyre-route packets onto pre-computed alternative paths after localdetection of a link failure, and prior to sending out failurenotifications to neighbouring nodes according, for example, to OSPF.Transient link errors are thus extremely short and most packets canreach their destination. In addition, network reconfiguration can bedelayed until it is determined that the link failure is persistent.

One specific IPFRR procedure is described in reference [4] below. Thisis known as “Not-via Addresses”. This procedure provides 100% link faultrecovery for at most one failed link. However, Not-via-Addressesrequires tunneling and the provision of two IP addresses per interface.In the case of a densely connected network, the administration andmanagement of tunneling interfaces and their addresses can becumbersome.

A problem that should always be addressed in IP networks is loopformation. This results in packets being transferred around a loopwithout ever reaching their final destination. Loops occupy valuablenetwork bandwidth and result in dropped packets. Another IPFRR procedureis known as Failure Insensitive Routing (FIR) (see reference [5]) andspecifically aims to reduce the risk of loop creation after a local andfast-reroute, without having to rely on tunnels. Routing tables areprovided at each router on a per line card basis. That is to say thatthe egress interface to which incoming packets are sent is determinednot only by the destination (IP address), but also by the ingressinterface on which the packet is received. Referring to FIG. 1, a sevenrouter IP network is illustrated. Consider for example router B. A firstrouting table associated with the ingress interface attached to router Sis configured to cause packets received at that interface and having anIP address routing prefix mapping to router D, to be forwarded to routerD across the B-C link. However, a second routing table associated withthe ingress interface to router C is configured to forward packetsreceived at that interface and having the same routing prefix, to beforwarded to router D across the B-A link.

Referring again to FIG. 1, consider the case where router S sends apacket destined for router D. The solid arrows illustrate the optimalroute, i.e. S→B→C→D. Now consider what happens when the link between Cand D fails. Upon detection of this failure, router C will returnpackets received from router B, to router B. As these packets arereceived by router B at a different ingress interface from which theywere received in the “outgoing” leg, despite the fact the destination IPaddress routing prefix is the same, router B will forward the packetover a different egress interface, namely the interface to router A.Thereafter, packets sent from S to D follow the path S→B→C→B→A→E→D(where the additional legs are illustrated by the dashed arrows in FIG.1). Of course, at some point the OSPF (or other) protocol will cause therouting tables to be updated across the network, resulting in a newoptimal route S→B→A→E→D. In the interim, however, no packets will bedropped.

Loop creation in FIR is still possible however. This is illustrated inFIG. 2. Consider that the C-D link has failed as described with respectto FIG. 1, and that packets are being sent between C and D along theS→B→C→B→A→E→D route. Consider further that the link between E and D nowfails. Router E will begin returning packets to router A which will inturn route them to B. Router B will pass packets to C which will returnthem to B and so on.

Rerouting and loop-prevention techniques are also described in: WO2006107875, WO 2006065439, WO 2006093642, WO 2006065440, US 20050063311,WO 2004019565, and U.S. Pat. No. 6,065,061.

It is noted that link failure and looping problems may arise in other,non-IP packet switched networks, for example in Ethernet networks.

SUMMARY

Loop creation occurs in FIR because FIR always seeks to use the shortestpath for forwarding, given the available links. However, if an interfacebased routing method could always determine whether a packet isfollowing a default path or if it is on a detour because of a fault, itwould be possible to drop the packets when the second error occurs.

According to a first aspect of the present invention there is provided amethod of routing packets across a packet switched network domain, thenetwork domain comprising a multiplicity nodes each of which comprisesat least one ingress interface and at least one egress interface. Theinvention is applicable in particularly, to IP networks comprising IProuters and to Ethernet networks comprising Ethernet switches. For eachnode as destination, a default branching and a detour branching aredefined, each of which specifies a route from each other node to thedestination node, where, for each node which is two-edge connected, thedefault and detour branchings do not share a common ingress interface.For a packet flow being sent from a source to a destination node, foreach node operating as an intermediate node, the following steps arecarried out:

-   -   receiving a packet at an ingress interface,    -   identifying an egress interface based upon the ingress interface        upon which the packet is received and the packet destination,    -   forwarding the packet via that egress interface if the connected        link is available and, if the connected link is not available,        forwarding the packet via an alternative egress interface        associated with said detour branching if the packet was received        at an ingress interface associated with said default branching        or dropping the packet if the packet was received at an ingress        interface associated with said detour branching.

Embodiments of the invention provide fault tolerance in so far as theydefine a detour branching from source node to destination node in theevent of a single link failure in the default branching. Switching fromthe default branch to the detour branch is fast as it is a per nodedecision. Furthermore, in the event of a failure of a link in the detourbranching, a node detecting the link failure implicitly knows that apacket is following the detour branching, based on the ingress interface(or source address) and the packet destination, and can drop the packetaccordingly. Additional interface addresses and tunneling are notrequired.

In order to construct default and detour branchings, for each singleedge connected node within the network, a virtual edge is included inone of said default and detour branchings, the default edgecorresponding to the real edge.

In the case that unused links remain after creation of the default anddetour branchings, these unused links may be added to the default and/ordetour branching, providing the loop creation is avoided.

At each node, for each ingress interface, a routing table may define foreach other destination node, an egress interface over which receivedpackets should be forwarded. There are a number of ways in which therouting tables may be defined and allocated. For example, the samerouting table may be provided to each ingress interface within a givennode, the routing table mapping ingress interface identifiers anddestination addresses to egress interface identifiers. In the case thatthe same routing table is provided to each ingress interface within agiven node, the routing table may map source addresses and destinationaddresses to egress interface identifiers. Alternatively, differentrouting tables may be provided to each ingress interface within a givennode.

According to one embodiment of the invention, for each routing table,where the ingress interface and a destination node map to a defaultbranching, the table may specify an egress interface associated with thedefault branching and a fallback egress interface associated with saiddetour branching and, where the ingress interface and a destination nodemap to said detour branching, the table may specify an egress interfaceassociated with the detour branching and no fallback egress interface.

According to a second aspect of the present invention there is provideda node for use in routing packets across a packet switched networkdomain. The invention is applicable in particular to node operating asIP routers. The node comprises:

-   -   at least two ingress interfaces and at least two egress        interfaces;    -   means for determining, for each node as destination, a default        branching and a detour branching across the network, each of        which specifies a route from each other node to the destination        node, where, for each node which is two-edge connected, the        default and detour branchings do not share a common ingress        interface;    -   means for receiving a packet at an ingress interface;    -   means for identifying an egress interface based upon the ingress        interface upon which the packet is received and the packet        destination,    -   means for forwarding the packet via that egress interface if the        connected link is available and, if the connected link is not        available, for forwarding the packet via an alternative egress        interface associated with said detour branching if the packet        was received at an ingress interface associated with said        default branching or dropping the packet if the packet was        received at an ingress interface associated with said detour        branching.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically a seven router network displayed as agraph, and employing Failure Insensitive Routing to recover from asingle failed link;

FIG. 2 illustrates the network of FIG. 1, with Failure InsensitiveRouting giving rise to a loop as a result of the failure of two links;

FIG. 3 illustrates schematically a router of an IP network;

FIG. 4 is a flow diagram illustrating a procedure for avoiding loopcreation in Failure Insensitive Routing;

FIG. 5 illustrates schematically the addition of multiple paths whencreating branchings for use in the process of FIG. 4;

FIG. 6 illustrates schematically edges in a seven router network for usein branching determination; and

FIG. 7 illustrates default and detour branchings within a seven routernetwork.

DETAILED DESCRIPTION

As is well known, ingress interfaces at IP routers are implemented byway of respective line cards, with each line card being configured witha routing or forwarding table. A typical router is illustrated in FIG. 3and comprises a hardware component 1 and a software component 2. Thesoftware component is arranged to determine routing tables based uponpreconfigured data and dynamic updates, e.g. based upon linkavailability. The hardware component comprises a plurality of ingressinterfaces 3 and a plurality of egress interfaces 4. Each ingressinterface is couple to a line card 5, and each line card stores arouting table provided by the software component. The line cardselectively couples the ingress interfaces to the egress interfaces. Aseparate failure detection module 6 monitors link availability at theingress and egress interfaces, and reports to the software and hardwaremodules.

The IPFRR based procedure described here is referred to as Loop-FreeFailure Insensitive Routing (LFIR) and relies upon the identification ofpaths from each router (within an IP network) to each other destinationrouter (within that same network) in such a way that when a routerreceives a packet from a specific ingress interface, the router canalways decide, based upon the configured routing table, if either thedefault path was used or the packet is on a detour due to a failed link.If the (onward) detour also fails, the packet must be dropped. There isno requirement for tunneling or additional flags as the path (default ordetour) can be determined solely from the ingress interface on which apacket is received, and the packet's destination.

Underlying Theory

An examination of Graph theory is helpful in arriving at a solution. Inparticular, the theorem presented in reference [6] teaches that abranching (spanning arborescence) rooted at vertex d in digraph G is aspanning tree directed in such a way that each vertex x≠d has one edgegoing out. (Note that branchings are usually defined in the reversedirection.). A 2-edge-connected digraph is one in which the cutting oftwo (or more) edges will disconnect at least one vertex from all othervertices. It is trivial to observe that, in the case of a2-edge-connected digraph, it is possible to find two edge-disjointbranchings in this graph rooted at any dεN(G).

One may observe that a branching is equivalent to a routing path for agiven destination d; if a packet can follow the directed edges of abranching rooted at d it reaches the destination. For the purposes of atheoretical analysis, the bidirectional links of real networks must beconsidered as two directed links. That is, if link {i,j} is part of thereal network, then the algorithm will work with two directed links:(i,j) and (j,i). It can be easily proven that the so constructed graphis also 2-edge-connected.

Considering further a 2-edge-connected network, network set-up involvesthe following pre-computation steps:

-   -   1. Convert the undirected graph of the original network G to a        digraph G′    -   2. Find two edge-disjoint branchings in G′ rooted at d for all        dεN(G′).    -   3. For each destination, label the two branchings (1 and 2).

Once set-up, packets arriving at a router are handled as follows:

-   -   1. When sending a packet from a source (first hop), use the        first branching if possible.    -   2. When a packet arrives at a router, determine the next hop        from the incoming interface and the destination address.    -   3. If the next-hop is reachable, forward it to that next hop.    -   4. If the next-hop is not reachable, determine whether that next        hop follows branching 1 or 2, then:    -   5. If the next hop follows branching 1, forward the packet to        the next hop following branching 2, or    -   6. If the next hop follows branching 2, drop the packet.

FIG. 4 is a flow diagram illustrating the routing process implemented ateach IP network router.

Branching Determination

It should be apparent from the above discussion that the key to LFIR isan effective algorithm for finding branchings, i.e. the alternativeroutes. [Note that the required branchings are directed towards thedestination, not away from it. This may require the reversal of knownbranching determination algorithms.] A known fast algorithm has beenproposed by Tarjan, see reference [7]. This requires O(eα(e,n)) time,where e=|E(G)|, n=|N(G)|, and α(e,n) is a very slowly growing functionrelated to the inverse of Ackerman's function. An alternative algorithmhas been proposed by Lovász, see reference [8]. This algorithm issimpler and also fast, it takes only O(e²) steps to find two branchingswith breadth first search. More importantly however, Lovász's algorithmallows application of a heuristic to decrease the length of the paths inthe primary branching (used as the default path, i.e., when there are noerrors): the directed edge from the set of edges that can be added tothe arborescence is always chosen, as this provides the shortest path tothe target of this edge. Using binary heap with this heuristic, O(e² loge) time is needed.

Bridges

An undirected graph can be partitioned into z disjunct “components”,such that these components are 2-edge-connected. Naturally, it ispossible that some components contain only one vertex. If the removal ofa link causes the network to split into two parts, it means that thislink is a “bridge” between two 2-edge-connected components. A bridgecannot be protected against failure; if it fails, there is noalternative link It is also true that if vertices s and d are not in thesame 2-edge-connected component, there is only one edge-disjoint pathbetween them. Using this idea it is possible to improve the LFIRprocedure by duplicating the bridges virtually in the graph of thenetwork. This new graph is 2-edge-connected, so after the transformationto a directed graph there will be at least two edge-disjoint branchings.Packets can follow these branchings as before. If a packet following abranching crosses a bridge, then the node after the bridge cannot decidewhich branching was used, so it should assume branching 1 for the nextforwarding. This improved method can correct all link failures exceptfor a bridge failure. If it is not sure that the network is at least2-edge-connected, it is needed to find the bridges. Bridges can be foundas described in reference [7] in a time O(eα(e,n)).

Using LFIR in a Distributed Environment

Using OSPF or IS-IS link state database, every router has a consistentview of the network topology but every router must find the same twobranchings. Lovász's branching search algorithm is deterministic exceptfor the case when there is more than one edge with the same distancefrom the root during the edge selection. In this case, each router mustpossess the same tie breaking rule to determine which edge will bechosen. The generic way to solve this is to give a unique priority toall links, and to always choose the link with the highest priority. Inthis way the construction of a branching is fully deterministic, so ifrouters have the same information about the network the same routingwill be calculated. Link priorities can be administratively setpriorities, or they can correspond to the addresses of interfacesconnected to links, with the higher or lower address having the higherpriority.

Implementation of the forwarding tables in real routers relies on acapability to assign different forwarding tables to differentinterfaces. The process is as follows.

-   -   If an edge {i,j} is part of branching 1, then the forwarding        table of the corresponding incoming interface of node j contains        the primary next-hop based on branching 1, and a backup entry        based on branching 2.    -   If a link {i,j} is part of branching 2, then the forwarding        table of the corresponding incoming interface of node j contains        only the primary next-hop based on branching 2, and there will        be no backup entries installed.

Like other IPFRR solution, the present proposal assumes that routerspossess some means to quickly detect the unreachability of a next-hop,i.e. the down state of an outgoing interface. In practice this is solvedby lower layer triggers or by dedicated Hello protocols, like BFD. Whena neighbour or outgoing interface is found to be down, a process has toquickly invalidate all entries in the routing tables pointing to thisinterface. If the link was part of branching 1, then removing it willstill leave the backup entry in the forwarding table. If it was part ofbranching 2 for a destination, the only route entry will be removed fromthe table and packets following branching 2 will be dropped.

Multiple-Edge Connected Networks

If a network is more than 2-edge-connected, i.e. n-edge connected (wheren>2), LFIR can also be used. Naturally an n-edge-connected network is2-edge-connected as well, so (at least) two branchings can be found. Ifa link fails, LFIR can correct this error as described above, so thenetwork can still transport the traffic and all the nodes havesufficient time to recognise the error. If the new topology is known inall the nodes, the two branchings can be computed again—because thenetwork is still at least 2-edge-connected—and the system is ready tocorrect further failures.

Broadcast Links

Some links in a network may be broadcast links instead of point-to-pointlinks. For example, an Ethernet “segment” may connect more than tworouters. In this case the incoming interface cannot be mapped to aspecific router. To resolve this situation, it is possible to set up foreach pair of routers, a separate virtual LAN (VLAN) which needs virtualinterfaces in both routers. In this way, the virtual interfaces can bedirectly mapped to a neighbouring router. Another option is not to makea differentiation based on the local incoming interface ID but on thelower layer source address of the neighbour, e.g., on the MAC address ofthe neighbouring router in case of an Ethernet segment, i.e.:

Destination IP Outgoing Source MAC address prefix inteface12-87-45-67-A9-7B 10.6.0.0/16 Eth3 . . . . . . . . .Multiple Paths

In traditional shortest path routing, Equal Cost Multi Paths (ECMP) areoften used for load sharing purposes. If, after finding the two disjointbranchings, there are some (directed) links that have not been used byeither branching, it is possible to add these links for load sharingpurposes to the primary branching given that it will not violate the DAG(directed acyclic graph) property of the primary branching, i.e. if itwill not cause a routing loop. If there still remain some links that arenot added to either branching, they can be added to the secondarybranching for load sharing purposes given that this will not violate theDAG (directed acyclic graph) property of the secondary branching.

This addition of multiple paths to the primary and secondary branchingsis illustrated in FIG. 5. As will be apparent from FIG. 5, if in atraditional network a router has n available ECMP paths to adestination, i.e., n outgoing alternative links, at least one of theselinks will be used by the primary branching, and another one for thesecondary branching. The remaining (n−2) alternatives can be added tothe primary branching as these will not violate the DAG property. Thisway, the proposed forwarding mechanism can also chose among at least(n−1) outgoing interfaces if there are no link failures. Of course, theproposal is advantageous over ECMP as not only the shortest alternativepaths can be added to the primary branching, but also each link whichdoes not cause a loop.

Loop Prevention During Global Convergence

The teachings in this invention disclosure are to be used for fastre-route in case of transient link failures. If the link failure issubsequently corrected, the system can again use the primary branching.In some cases however, the topology changes by administrative input(e.g. addition a new node) or the failure is persistent requiring globalre-convergence. Network wide re-convergence, i.e., when routersone-by-one recalculate their forwarding tables, may cause transientrouting loops. The proposed forwarding mechanism does not change this inany respect and it may still occur.

Illustrative Example

FIG. 6 shows a simple seven router network represented as a graph.Routers A to E are two edge connected, i.e. having bi-directional linksto two neighbouring routers. Routers S and F have bidirectionalconnections to only a single neighbouring router. The respective linkstherefore represent bridges as described above. In order to determine adefault and a detour branching (for each destination router) it istherefore necessary to create for each of S and F a second virtualbridge, as illustrated.

Application of Graph theory allows the default and detour branchings tobe identified within the network of FIG. 6, although in this example theprocess is trivial. Considering router D as the destination router, thetwo branchings are shown in FIG. 7, with the default branching beingshown with solid lines and the detour branching being shown with dashedlines. It can be seen that every other router can reach router D byeither the default branching or the detour branching.

To illustrate the loop prevention afforded by LFIR, assume that router Sis sending packets to router D, initially via the default branching.Packets will follow the path S→B→C→D. In the event that the link C-Dfails, router C will detect this and will begin returning packetsreceived from B, to D, according to the detour branching. Thus, packetswill now follow the route S→B→C (default branching)→B→A→E→D (detourbranching). Assume further that the link E-D now fails. The routingtable at E associated with the ingress interface from A will recordthat, for packets destined for D, that ingress interface belongs to thedetour path. No fallback route is contained within the routing table andthe packets arriving from A will be dropped, i.e. the packets are notreturned to A and no loop results. Of course, packets sent by S will notreach D until such time as one of the failed links, C-D and E-D,recovers.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiments withoutdeparting from the scope of the invention. For example, whilst theinvention has been exemplified above with reference to IP networks, theinvention is also applicable to Ethernet networks in which packetforwarding is handled by Ethernet switches.

REFERENCES

-   1. D. Thaler: Multipath issues in unicast and multicast next-hop    selection. Internet Engineering Task Force: RFC 2991 (November 2000)-   2. Alia Atlas: Loop-free alternates for ip/ldp local protection.    Internet Draft, available online:    http://tools.ietf.org/html/draft-ietf-rtgwg-ipfrr-spec-base-00    (March 2005)-   3. S. Bryant, C. Filsfils, S. Previdi, M. Shand: IP Fast-reroute    Using Tunnels. Internet Draft, available online:    http://tools.ietf.org/html/draft-bryant-ipfrr-tunnels-02 (April    2005)-   4. S. Bryant, M. Shand, S. Previdi: IP Fast Reroute Using Not-via    Addresses. Internet Draft, available online:    http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-ipfrr-notvia-addresses-00.txt    (December 2006)-   5. S. Nelakuditi, S. Lee, Y. Yu, Z.-L. Zhang, C-N. Chuah: Fast Local    Rerouting for Handling Transient Link Failures. Accepted for    publication in IEEE/ACM Transactions on Networking, available    online: http://arena.cse.sc.edu/papers/fir.ton.pdf (December 2006)-   6. J. Edmonds: Edge-disjoint branchings. Combinatorial    Algorithms (1973) 91-96-   7. R. E. Tarjan: Edge-disjoint spanning trees and depth-first    search. Inf. Proc. Letters (1974) 51-53-   8. L. Lovász: On two minimax theorems in graph theory, Journal of    Combinatorial Theory (1976) 96-103

The invention claimed is:
 1. A method of routing packets across a packetswitched network domain, the network domain comprising a plurality ofnodes, wherein the plurality of nodes includes a source node, adestination node, and one or more intermediate nodes, and wherein eachnode in the plurality of nodes comprises at least one ingress interfaceand at least one egress interface, the method comprising: for thedestination node, defining a default branching and a detour branching,each of which specifies a route from each node other than thedestination node to the destination node; and performing the followingat each node operating as an intermediate node for a packet flow beingsent from the source node to the destination node, wherein eachintermediate node in said plurality of nodes is a two-edge connectednode in which the default branching and the detour branching do notshare a common ingress interface, and wherein each two-edge connectednode is connected to at least two adjacent nodes via a plurality ofcommunication links: receiving a packet at an ingress interface, whereinthe packet is sent to a packet destination, identifying an egressinterface based solely upon the ingress interface upon which the packetis received and the packet destination, without a requirement for arouting flag, forwarding the packet via the identified egress interfaceif a connected link connecting the intermediate node to an adjacent nodecoupled to the identified egress interface is available, if theconnected link is not available, rerouting the packet via an alternativeegress interface associated with the detour branching if the packet wasreceived at an ingress interface associated with the default branching,and if the connected link is not available, dropping the packet if thepacket was received at an ingress interface associated with the detourbranching.
 2. The method according to claim 1, wherein for each singleedge connected node within the network domain, a virtual edge isincluded in one of the default branching and the detour branching, thedefault edge corresponding to the real edge.
 3. The method according toclaim 1, further comprising, after the step of defining a defaultbranching and a detour branching, adding any unused links to at leastone of the following: the default branching; and the detour branching.4. The method according to claim 1, further comprising: providing ateach node, for each ingress interface, a routing table defining, foreach node other than the destination node, an egress interface overwhich received packets should be forwarded.
 5. The method according toclaim 4, wherein the same routing table is provided to each ingressinterface within a given node, the routing table mapping ingressinterface identifiers and destination addresses to egress interfaceidentifiers.
 6. The method according to claim 4, wherein the samerouting table is provided to each ingress interface within a given node,the routing table mapping source addresses and destination addresses toegress interface identifiers.
 7. The method according to claim 4,further comprising: providing different routing tables to each ingressinterface within a given node.
 8. The method according to claim 4,further comprising: for each routing table, where the ingress interfaceand the destination node map to the default branching, specifying in therouting table an egress interface associated with the default branchingand a fallback egress interface associated with the detour branchingand, where the ingress interface and the destination node map to thedetour branching, specifying in the routing table an egress interfaceassociated with the detour branching and no fallback egress interface.9. The method according to claim 1, wherein the packet switched networkdomain is an Internet Protocol (IP) network domain, and the nodes are IProuters.
 10. The node according to claim 1, wherein the packet switchednetwork domain is an Ethernet Network domain, and the nodes are Ethernetswitches.
 11. An intermediate node for use in routing packets across apacket switched network domain that contains a plurality of nodes,wherein the plurality of nodes includes a source node, a destinationnode, and one or more intermediate nodes, wherein a default branchingand a detour branching are defined across the network domain for thedestination node, wherein each of the default branching and the detourbranching specifies a route from each node other than the destinationnode to the destination node, and wherein each intermediate nodecomprises at least two ingress interfaces and at least two egressinterfaces, wherein each intermediate node is configured to perform thefollowing for a packet flow being sent from the source node to thedestination node: receive a packet at an ingress interface, wherein thepacket is sent to a packet destination, and wherein each intermediatenode is a two-edge connected node in which the default branching and thedetour branching do not share a common ingress interface, and whereineach two-edge connected node is connected to at least two adjacent nodesvia a plurality of communication links; identify an egress interfacebased solely upon the ingress interface upon which the packet isreceived and the packet destination, without a requirement for a routingflag; forward the packet via the identified egress interface if aconnected link connecting the intermediate node to an adjacent nodecoupled to the identified egress interface is available; if theconnected link is not available, reroute the packet via an alternativeegress interface associated with the detour branching if the packet wasreceived at an ingress interface associated with the default branching;and if the connected link is not available, dropping the packet if thepacket was received at an ingress interface associated with the detourbranching.
 12. The intermediate node according to claim 11, wherein theintermediate node is an Internet Protocol (IP) router for use within anIP network domain.
 13. The intermediate node according to claim 11,wherein the intermediate node is an Ethernet switch for use within anEthernet network domain.